Create a GeoServer Release

Summary "svn update" geotools. "maven build" "svn update" geoserver & build run CITE tests write README file and change the version references to the new version tag geotools and geoserver Export Docs from Confluence "ant release-all" to do the binary and WAR release make the .exe installer release on JIRA (make sure all tasks are closed or moved to a future version upload to source forge update to codehaus update website with new information adverstise release

Prerequisites

Check you do have the following before going on, or you won't be able to perform the release:

• You do have a working Geoserver build environment
• You do have commit rights on svn repository
• You are an admin in the Geoserver Sourceforce project
• You do have a stable and relatively fast internet connection (lots of data to upload)

Checkout from Subversion

Ensure you have an up-to-date source tree by checking out from scratch or performing an update.

Check Geotools dependencies

Geoserver final releases are released against a stable version of Geotools. This means that either:

1. there is a stable geotools version already that satisfies Geoserver needs
2. Geoserver needs a stable release of Geotools to be created (because it needs some bug fixes
   committed only on the gt2 stable branch, but still unreleased)

On the contrary, it's ok to release a milestone or an RC against a geotools SNAPSHOT of a stable branch (try not to release release against trunk or an unstable branch).

At the same time, check if the epsg-hsql module contains the latest EPSG database release. If not, and you have to make a geotools release anyways, check with the module mantainer if it's possible to have an update to the latest one. On the contrary, if you're building against a stable release, don't bother making a new one just for updating the epsg provider (given that a geotools release takes at least half a day).

In either case, run CITE tests. If you find that more bugfixes are needed, commit them to the stable branch and declare a code freeze and the need for a new stable release on the geotools developer mailing list, and keep the freeze until all CITE tests do pass and you have a new geotools stable release that Geoserver can use.

If you are building on a machine with no graphical user interface some tests will fail. You can get around this by appending -Djava.awt.headless=true to your mvn commands.

Testing

The first step in a release is testing. This step should actually probably occur between every step of the release, as past experience has shown that testing each step of the way will definitely catch a few errors, as the project and the release process are both complex. We recommend checking out geoserver from svn in a completely new directory on your machine.

There are a number of different tests that should be performed.

Build and unit test

Make sure the main pom.xml refers to the right Geotools version, and that the Geoserver version is the one you're releasing.

<properties>
	<gs.version>1.4.0-RC2</gs.version>
	<gt.version>2.2.2-SNAPSHOT</gt.version>
</properties>

Do a full build (mvn clean install), which will run unit tests along the way. If a test fails, it must be fixed before releasing.

Tag geotools so you know what revision geoserver was released against. Ideally you would just do a full geotools release as well.

Hand Testing

This simply means try out GeoServer and observe the results on a few tests. To do this:

1. From the web module:

   [/dev/geoserver/web]% mvn -DconfigId=release -DconfigDirectory=../../configuration clean install

2. From the same module, start the embedded jetty container:

   [/dev/geoserver/web]% mvn jetty:run

3. Then you should just issue a few wms and wfs requests. The easiest way is to go to the demo section and run the sample requests, and check results are ok.
4. A cursory look thru the configuration panels is a good idea too.

If any error is found, it must be fixed and the build and test process restarted.

Cite Tests

Running Cite Tests A step-by-step guide for the CITE tests is available here.

The cite tests will take at least a up to an hour to run all the way, so we recommend working on some documentation or the readme file while they run. The tests are available at http://cite.opengeospatial.org/. To run them you will need a public instance of GeoServer outside of a firewall.

The unit tests and hand tests should be run at most every step of the way, as often as possible, just to make sure any little changes did not cause things to go wrong. On the day of a release the cite tests should also be run several times. For a point release all cite tests must pass. For alpha and beta releases they do not all need to pass, but a good majority is recommended, since they represent the core functionality of GeoServer and users expect those operations to work. GeoServer should also be tested on several servlet containers and operating systems. We have been mainly supporting Tomcat and Resin, on both Windows and Linux. Testing different versions of Linux and Windows is probably a bit tough, but at each one version of each should be tested. We recommend testing Tomcat 4 and 5 and Resin 2 and 3, since there are many users of both. If one works the other should as well, it is just a good idea to make sure. Yes, we know that all these tests may seem a bit ridiculous, but maintaining a high quality of releases is very important to the success of GeoServer, and generally the tests will reveal a few errors that were not present before. And even if none are found it allows you to feel much more confident in the quality of the release.

Create a README

The README file ( located in the release directory ) must be updated for every release. When writing the README follow the following guidelines:

1. It should be few paragraphs, highlighting the new features of the release
2. It should contain thanks you's and credits to anyone who contributed during the development cycle, contributions include testing, reporting bugs, submitting patches, etc...
3. It should contain a reference to the jira issue log
4. It should contain a reference to the version of geotools the release is built against

Example README:

GeoServer 1.4.0
---------------

Major features / improvements of this release include:

- new SLD editor
- WMS PutStyles / GetStyles support
- WFS filter parsing bug fix

Special thanks to the following people for their contributions:

- Joe Schmo: WFS filter parsing patch

The issue log for this release can be found here:

http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10311&fixfor=11555

Based on Geotools 2.2.0 (tag = 2.2.0).

Update GeoServer Version

Update all files which contain a reference to the old version number.

A handy unix command for doing so is:

find . -exec sed -i 's/1.4.0/1.4.1/g' {} \;

On Windows you can do the same using, for example, the free "Simple Search and Replace" utility from RJL software.

The set of files to be updated include:

• all pom.xml files
• release/geoserver.nsi
• web/src/main/java/ApplicationProperties*

Export Documentation from Confluence

You should now head over to the Confluence Wiki and export the docs:

1. http://docs.codehaus.org/spaces/exportspace.action?key=GEOSDOC.
2. Scroll down to the bottom of the page and hit the Export button. It will take about 30 seconds to generate the zip file.
3. Save the generated zip file and extract the contents to geoserver/release/. Be sure to remove any existing "GEOSDOC" directories from the release directory.

Build Release Artifacts

1. First of all, make sure your configuration/release directory does not contain any extra file or local modifications. To make extra sure, just wipe it out and svn up it back.
2. From the root of the release directory

   [/dev/geoserver/release]% mvn clean install

   [GEOSDEV:INFO] Copying ...org\mortbay\jetty\jsp-api-2.1\6.0.0beta16\jsp-api-2.1-6.0.0beta16.jar to
   C:\devel\geoserver\1.4.x\release\target\dependency\jsp-api-2.1-6.0.0beta16.jar
   [GEOSDEV:INFO] Copying ...commons-el\commons-el\1.0\commons-el-1.0.jar to
   C:\devel\geoserver\1.4.x\release\target\dependency\commons-el-1.0.jar
   [GEOSDEV:INFO] Copying ...org\mortbay\jetty\jetty-util\6.0.0beta16\jetty-util-6.0.0beta16.jar to
   C:\devel\geoserver\1.4.x\release\target\dependency\jetty-util-6.0.0beta16.jar
   [GEOSDEV:INFO] Copying ...org\mortbay\jetty\jsp-2.1\6.0.0beta16\jsp-2.1-6.0.0beta16.jar to
   C:\devel\geoserver\1.4.x\release\target\dependency\jsp-2.1-6.0.0beta16.jar
   [GEOSDEV:INFO] ------------------------------------------------------------------------
   [GEOSDEV:INFO] BUILD SUCCESSFUL
   [GEOSDEV:INFO] ------------------------------------------------------------------------
   [GEOSDEV:INFO] Total time: 3 seconds
   [GEOSDEV:INFO] Finished at: Tue Jun 06 10:08:31 CEST 2006
   [GEOSDEV:INFO] Final Memory: 6M/11M
   [GEOSDEV:INFO] ------------------------------------------------------------------------

3. From the root of the source tree:

   [/dev/geoserver]% mvn -DconfigId=release -DconfigDirectory=../../configuration clean install 
   [/dev/geoserver]% mvn -DconfigId=release -DconfigDirectory=../../configuration javadoc:javadoc assembly:attached -Dmaven.test.skip=true

   [GEOSDEV:INFO] [assembly:assembly]
   [GEOSDEV:INFO] Building zip: C:\devel\geoserver\1.4.x\target\release\geoserver-1.4.0-M0-src.zip
   [GEOSDEV:INFO] Building zip: C:\devel\geoserver\1.4.x\target\release\geoserver-1.4.0-M0-war.zip
   [GEOSDEV:INFO] Building zip: C:\devel\geoserver\1.4.x\target\release\geoserver-1.4.0-M0-javadoc.zip
   [GEOSDEV:INFO] Building zip: C:\devel\geoserver\1.4.x\target\release\geoserver-1.4.0-M0-bin.zip
   [GEOSDEV:INFO]
   [GEOSDEV:INFO]
   [GEOSDEV:INFO] ------------------------------------------------------------------------
   [GEOSDEV:INFO] Reactor Summary:
   [GEOSDEV:INFO] ------------------------------------------------------------------------
   [GEOSDEV:INFO] GeoServer ............................................. SUCCESS [GEOSDEV:27.406s]
   [GEOSDEV:INFO] GeoServer Main Module ................................. SUCCESS [GEOSDEV:5.703s]
   [GEOSDEV:INFO] GeoServer Validation Module ........................... SUCCESS [GEOSDEV:1.218s]
   [GEOSDEV:INFO] GeoServer Web Feature Service Module .................. SUCCESS [GEOSDEV:2.610s]
   [GEOSDEV:INFO] GeoServer Web Map Service Module ...................... SUCCESS [GEOSDEV:3.265s]
   [GEOSDEV:INFO] GeoServer Configuration Deployment PlugIn ............. SUCCESS [GEOSDEV:1.204s]
   [GEOSDEV:INFO] GeoServer Web Application Module ...................... SUCCESS [GEOSDEV:20.312s]
   [GEOSDEV:INFO] GeoServer Test Module ................................. SUCCESS [GEOSDEV:2.594s]
   [GEOSDEV:INFO] ------------------------------------------------------------------------
   [GEOSDEV:INFO] ------------------------------------------------------------------------
   [GEOSDEV:INFO] BUILD SUCCESSFUL
   [GEOSDEV:INFO] ------------------------------------------------------------------------
   [GEOSDEV:INFO] Total time: 1 minute 5 seconds
   [GEOSDEV:INFO] Finished at: Tue Jun 06 10:44:11 CEST 2006
   [GEOSDEV:INFO] Final Memory: 14M/33M
   [GEOSDEV:INFO] ------------------------------------------------------------------------

A target/release directory should have been created which contains the following artifacts:

geoserver-<version>-bin.zip
geoserver-<version>-javadoc.zip
geoserver-<version>-src.zip
geoserver-<version>-war.zip
geoserver-<version>-doc.zip

Create the Installer ( Windows Platform Only )

In order to create the windows installer, you will need to download and install the Nullsoft Scriptable Install System (NSIS).

1. make a new temporary directory ( refered to as temp ).
2. uncompress the target/release/geoserver-<version>-bin.zip to temp:

   temp/
      + geoserver/
           + GPL.txt
           + LICENSE.txt
           + README.txt
           + bin/
           + lib/
       ....

3. copy release/geoserver.nsi to temp/geoserver
4. copy release/dataDirPage.ini to temp/geoserver
5. copy release/splash.bmp_ to temp/geoserver
6. right click on the the geoserver.nsi file and select "Compile NSIS Script"

Upon successful creation of the installer you should see the following:

In your temporary directory, you should see a "geoserver-<version>.exe"!

Tag and Branch

Commit any remaining changes to your local checkout.

1. Create a tag:

   svn copy https://svn.codehaus.org/geoserver/trunk https://svn.codehaus.org/geoserver/tags/<version>

2. If the release is a "major release"( one in which the secondary version number has changed ), create a branch:

   svn copy svn copy https://svn.codehaus.org/geoserver/trunk https://svn.codehaus.org/geoserver/branches/<major>-<secondary>-x

   Where major is the major and secondary version numbers. Example: 1.4.x

Test Runnable Artifacts

It is always a good idea to "hand-test" the runnable artifacts. This includes:

1. Running the installer and trying it out some of the demo scripts
2. Unarchiving the binary distrubution and trying out some of the demo scripts
3. Deploying the war file in a servlet container and trying out some of the demo scripts

Uploading to SourceForge

The next step is to upload to sourceforge. They have great docs on how to perform the release. You will need release tech permissions to perform the release. For more information go to: http://sf.net/project/admin/editpackages.php?group_id=25086 Since they cover it so well we will just do the quick version:

ftp to upload.sf.net/incoming - put all the files in release there. Yes, it's an anonymous ftp and you can upload whatever you want without control.
Go to the webpage above, and click 'add release' next to geoserver. Call it
     geoserver-version.number - like geoserver-1.3.0
Upload the release notes - just use the readme as release notes.
     + Be sure to click to preserver the formating.
Find the file in the list of files on upload.sf.net and add them to the release
Set the processor to any, and the type to source.gz.
Notify the users watching the release.
Download your newly released file and test it again to make sure that everything is perfect.

Uploading DataStore Extensions

The release process now generates the zip files for the data store extensions. These also need to be uploaded to Sourceforge. Make sure you release under the GeoServer Extensions project.
The files are located under the target/release directory.

Uploading to Codehaus

Next is to update the GeoServer jars in the Codehaus Maven Repository. This is done to allow other projects that depend on GeoServer through maven dependencies to be updated. Instructions here.

Updating the Website

Various places on the web need to be updated to reflect the fact that we released. Depending on the release it should go under the Latest or Stable pages. Create a new child page, select "Download" as the page template, and fill in the GeoServer release number and SourceForge release id.
Once the page is created and the links in it are updated to point to the sourceforge download page, edit the Latest or Stable pages to include your page instead of the previous page.

Update the Javadocs

The javadocs have been generated as part of the release process and they should be placed up on the web site.
There is a webdav folder that you can put them on. The address is http://geoserver.codehaus.org/javadocs/stable/ and you need to use your codehaus username and password.
There is the stable folder and the experimental folder. Stable releases go under stable. These releases are on the main stable branch or a stable release off of trunk.

Accessing WebDav in Windows:

In Windows Explorer, open up "My Network Places"
In there, double click on Add Network Place
Use the address: *https://dav.codehaus.org/geoserver/*
Use your codehaus username and password.
Then just drag the files into the directory where the javadocs live (javadocs/).

Accessing WebDav in Linux with KDE:

In Konqueror, enter "webdavs://dav.codehaus.org/geoserver" on the address bar
Supply your username and password when prompted
Then just drag the files into the directory where the javadocs live (javadocs/).

Announcing the Release

The final step is announcing to the world that you just put out a release. The first place is the geoserver homepage. You'll probably need admin status to add things to the web page. To get admin status you will need to sign up for an account on the web page, and then a current admin can up your privelages. The announcement should be a few paragraphs long, the first paragraph should give the basic information and direct links to the download. The following paragraphs should give more information and often a good little story. These sometimes get picked up by others, either from the homepage or the email list. So check them for typos and make them readable so someone else can grab a quick quote on the release. Then email the geoserver devel list, as many people are pretty much only on the list for release announcements. Next we generally update the freshmeat entry, as it gets quite a few hits as the release will appear on the front page. The story can also be added as a story on sourceforge, as sometimes those will get picked up and placed on the main sourceforge page. Variations or cut and paste from the homepage story work just fine. Any other places to announce it are fair game. Generally at least the freegis entry should be updated online, if a major release then the freegis list can be emailed directly. For 1.1.0 the story appeared on osdir.com and dev.java.net, but we did not do any direct announcing there, so I am not sure what the policy is on submitting stuff to them.

releaseNSIS.PNG (image/png)